Summary

Adds proper SQL type support for Short and java.math.BigDecimal across the
table-sink write path. Previously neither had a JDBC type mapping, so the sink
created such columns as VARCHAR(255) (numbers stored as text, with no numeric
ordering/aggregation in the DB). This PR maps them to real numeric SQL types and
binds their values correctly on both the Java and Spark execution paths.

Changes

1. Type mapping (SqlTypeUtils)

• Short / short → SMALLINT
• BigDecimal → NUMERIC(38,18)
• The PostgreSQL dialect inherits both from the default map.

2. Value binding (the DDL type alone is not enough)
Mapping the column type without binding the value would bind a string into a
numeric column. Each in-JVM sink is fixed:

• JavaTableSink: bind via PreparedStatement.setShort(...) / setBigDecimal(...)
  instead of the setString fallback.
• SparkTableSink: map Short → DataTypes.ShortType and
  BigDecimal → DataTypes.createDecimalType(38, 18), so the DataFrame schema
  (and the JDBC write derived from it) produces SMALLINT / NUMERIC(38,18).

Why NUMERIC(38,18) rather than a bare NUMERIC

A bare NUMERIC is not portable for decimals. Per the SQL standard, omittting
the scale means scale 0, so most engines create an integer column and silently
truncate the fractional part: H2, MySQL (DECIMAL(10,0)), SQL Server
(DECIMAL(18,0)), Derby, DB2 all do this (e.g. 12.345 → 12). PostgreSQL is the
lenient exception (bare NUMERIC is unbounded), which can hide the bug. An
explicit scale avoids the truncation on every database.

Why specifically 38 and 18

These are not arbitrary: (38, 18) is Spark's DecimalType.SYSTEM_DEFAULT —
the precision/scale Spark assigns to a decimal when none is otherwise known
(38 is also the maximum precision Spark's Decimal supports, and a value widely
supported by Oracle/SQL Server). We deliberately reuse the same values on the
Java/DDL path (SqlTypeUtils → NUMERIC(38,18)):

• 38 = max total significant digits (generous headroom),
• 18 = digits after the decimal point (ample for monetary/rate data),
• and, crucially, this makes the Java and Spark sinks emit identical column
  types for a BigDecimal. In Wayang the optimizer decides which platform runs
  the sink, so the output schema must not depend on that choice — matching Spark's
  default keeps both paths consistent.

Trade-off: a fixed scale pads short values with trailing zeros
(12.345 → 12.345000000000000000). This is numerically identical and is exactly
what the Spark path already produced;=, in return decimals aree portable and lossless
across all databases.

Tests

• SqlTypeUtilsTest: the full default type map (incl. Short → SMALLINT,
  BigDecimal → NUMERIC(38,18)) and PostgreSQL inheritance.
• SparkTableSinkTest:
  • direct mapping checks for getSparkDataType(...) — the whole Java-class →
    Spark DataType table, the String fallback, and explicitly
    BigDecimal → DecimalType(precision=38, scale=18);
  • an end-to-end write of all supported types to in-memory H2, asserting the
    round-tripped values and the created column types (SMALLINT, NUMERIC(38,18)).
• JavaTableSinkTest: the analogous end-to-end test for the Java sink.

All tests run against in-memory H2 — no external database required.

Notes

• The in-database JDBC sinks (PostgresTableSinkOperator, etc.) are unaffected :
  they compose CREATE TABLE ... AS SELECT and let the DB infer types, so they
  never bind a Java value or use SqlTypeUtils.
• getSparkDataType was widened from private to package-private only to make
  the mapping unit-testable.